IRIX does not support DES encryption, so the _AAAA_UUUU_TTTT_HHHH______DDDD_EEEE_SSSS authentication
discussed here and the various encryption routines are not functional.
These routines are not present in libc. Stubs are provided as part of
libnsl to allow linking of programs, but they return an error condition,
DESERR_NONE, if invoked.
DDDDEEEESSSSCCCCRRRRIIIIPPPPTTTTIIIIOOOONNNN
RPC library routines allow C programs to make procedure calls on other
machines across the network. First, the client calls a procedure to send
a data packet to the server. Upon receipt of the packet, the server
calls a dispatch routine to perform the requested service, and then sends
back a reply.
RPC supports various authentication flavors. Among them are:
_AAAA_UUUU_TTTT_HHHH______NNNN_OOOO_NNNN_EEEE (none) no authentication.
_AAAA_UUUU_TTTT_HHHH______SSSS_YYYY_SSSS Traditional UNIXr-style authentication.
_AAAA_UUUU_TTTT_HHHH______DDDD_EEEE_SSSS DES encryption-based authentication.
The _aaaa_uuuu_tttt_hhhh_dddd_eeee_ssss______gggg_eeee_tttt_uuuu_cccc_rrrr_eeee_dddd and _aaaa_uuuu_tttt_hhhh_dddd_eeee_ssss______ssss_eeee_cccc_cccc_rrrr_eeee_aaaa_tttt_eeee routines implement the
_AAAA_UUUU_TTTT_HHHH______DDDD_EEEE_SSSS authentication flavor. The keyserver daemon _kkkk_eeee_yyyy_ssss_eeee_rrrr_vvvv [see
_kkkk_eeee_yyyy_ssss_eeee_rrrr_vvvv(1M)] must be running for the _AAAA_UUUU_TTTT_HHHH______DDDD_EEEE_SSSS authentication system to
work.
RRRRoooouuuuttttiiiinnnneeeessss
See _rrrr_pppp_cccc(3N) for the definition of the _AAAA_UUUU_TTTT_HHHH data structure.
_aaaa_uuuu_tttt_hhhh_dddd_eeee_ssss______gggg_eeee_tttt_uuuu_cccc_rrrr_eeee_dddd is the first of the two routines which interface to
the RPC secure authentication system known as _AAAA_UUUU_TTTT_HHHH______DDDD_EEEE_SSSS. The second
is _aaaa_uuuu_tttt_hhhh_dddd_eeee_ssss______ssss_eeee_cccc_cccc_rrrr_eeee_aaaa_tttt_eeee, below. _aaaa_uuuu_tttt_hhhh_dddd_eeee_ssss______gggg_eeee_tttt_uuuu_cccc_rrrr_eeee_dddd is used on the server
side for converting an _AAAA_UUUU_TTTT_HHHH______DDDD_EEEE_SSSS credential, which is operating
system independent, into an _AAAA_UUUU_TTTT_HHHH______SSSS_YYYY_SSSS credential. This routine
returns _1111 if it succeeds, _0000 if it fails.
_****_u_i_d_p is set to the user's numerical ID associated with _a_d_c. _****_g_i_d_p
is set to the numerical ID of the group to which the user belongs.
_****_g_i_d_l_i_s_t contains the numerical IDs of the other groups to which the
user belongs. _****_g_i_d_l_e_n_p is set to the number of valid group ID
entries in _****_g_i_d_l_i_s_t [see _nnnn_eeee_tttt_nnnn_aaaa_mmmm_eeee_2222_uuuu_ssss_eeee_rrrr, below].
_aaaa_uuuu_tttt_hhhh_dddd_eeee_ssss______ssss_eeee_cccc_cccc_rrrr_eeee_aaaa_tttt_eeee, the second of two _AAAA_UUUU_TTTT_HHHH______DDDD_EEEE_SSSS authentication
routines, is used on the client side to return an authentication
handle that will enable the use of the secure authentication system.
The first parameter _n_a_m_e is the network name, or _n_e_t_n_a_m_e, of the
owner of the server process. This field usually represents a
hostname derived from the utility routine _hhhh_oooo_ssss_tttt_2222_nnnn_eeee_tttt_nnnn_aaaa_mmmm_eeee, but could
also represent a user name using _uuuu_ssss_eeee_rrrr_2222_nnnn_eeee_tttt_nnnn_aaaa_mmmm_eeee, described below. The
second field is window on the validity of the client credential,
given in seconds. A small window is more secure than a large one,
but choosing too small of a window will increase the frequency of
resynchronizations because of clock drift. The third parameter,
_t_i_m_e_h_o_s_t, the host's name, is optional. If it is _NNNN_UUUU_LLLL_LLLL, then the
authentication system will assume that the local clock is always in
sync with the _t_i_m_e_h_o_s_t clock, and will not attempt
resynchronizations. If a timehost is supplied, however, then the
system will consult with the remote time service whenever
resynchronization is required. This parameter is usually the name of
the RPC server itself. The final parameter _c_k_e_y is also optional.
If it is _NNNN_UUUU_LLLL_LLLL, then the authentication system will generate a random
DES key to be used for the encryption of credentials. If _c_k_e_y is
Convert from a domain-specific hostname _h_o_s_t to an operating-system
independent netname. Return _1111 if it succeeds, and _0000 if it fails.
Inverse of _nnnn_eeee_tttt_nnnn_aaaa_mmmm_eeee_2222_hhhh_oooo_ssss_tttt. If _d_o_m_a_i_n is _NNNN_UUUU_LLLL_LLLL, _hhhh_oooo_ssss_tttt_2222_nnnn_eeee_tttt_nnnn_aaaa_mmmm_eeee uses the
default domain name of the machine. If _h_o_s_t is _NNNN_UUUU_LLLL_LLLL, it defaults to
_kkkk_eeee_yyyy______dddd_eeee_cccc_rrrr_yyyy_pppp_tttt_ssss_eeee_ssss_ssss_iiii_oooo_nnnn is an interface to the keyserver daemon, which is
associated with RPC's secure authentication system (_AAAA_UUUU_TTTT_HHHH______DDDD_EEEE_SSSS
authentication). User programs rarely need to call it, or its
associated routines _kkkk_eeee_yyyy______eeee_nnnn_cccc_rrrr_yyyy_pppp_tttt_ssss_eeee_ssss_ssss_iiii_oooo_nnnn, _kkkk_eeee_yyyy______gggg_eeee_nnnn_dddd_eeee_ssss and
_kkkk_eeee_yyyy______eeee_nnnn_cccc_rrrr_yyyy_pppp_tttt_ssss_eeee_ssss_ssss_iiii_oooo_nnnn is a keyserver interface routine. It takes a
server netname _r_e_m_o_t_e_n_a_m_e and a DES key _d_e_s_k_e_y, and encrypts it
using the public key of the server and the secret key associated
with the effective UID of the calling process. It is the inverse of
_kkkk_eeee_yyyy______dddd_eeee_cccc_rrrr_yyyy_pppp_tttt_ssss_eeee_ssss_ssss_iiii_oooo_nnnn. This routine returns _0000 if it succeeds, _----_1111 if it
